Existing and developing wireless communication networks offer increasing ranges and types of communication services to users. In almost all instances, users must be authenticated or otherwise verified before granting access to services. The particular authentication required often depends on the type of service being accessed. For example, services available through an Internet Protocol Multimedia Core Network Subsystem (referred to as “IMS” or “IMS network”) generally require IMS registration of the user terminal attempting to access such services. This registration includes an Authentication and Key Agreement (AKA) security procedure, which involves Session Initiation Protocol (SIP) signaling between the user terminal and the IMS network.
More particularly, an IMS network uses two identities for a given user terminal. The first identity is an IP Multimedia PUblic key identity (IMPU), and the second identity is an IP Multimedia Private Identity (IMPI). The IMPI may, for example, be derived from the user terminal's International Mobile Subscriber Identity (IMSI). The Third Generation Partnership Project (3GPP) standards make that method of key derivation mandatory, where IMPIs are formed using identity information from the Universal Subscriber Identity Modules (USIMs) implemented in user terminals.
Generally, a user terminal has one IMPI, but it may have a plurality of IMPUs. The IMPUS are, however, correlated to the IMPI. A Home Subscriber Server (HSS), for example, stores a list of IMPUs for each IMPI. For IMS registration, including IMS-AKA authentication, a Call Session Control Function (CSCF) communicates with the HSS to obtain an authentication vector. The user terminal communicates with the CSCF using a SIP-based AKA authentication protocol.
Other applications available outside of the IMS network services may require other authentication processing. For example, a number of applications require authentication based on the Generic Bootstrapping Architecture (GBA), which also uses AKA-based authentication (based on HTTP signaling). A Bootstrapping Server Function (BSF) contacts the terminal's HSS to obtain the AKA vector, and to obtain General User Security Settings (GUSS) for GBA-AKA authentication of the user terminal.
More particularly, GBA-based authentication first establishes a shared secret between the network and a user terminal by running a bootstrapping procedure. The shared secret is then used between Network Application Functions (NAFs) and the user terminal for authentication purposes, wherein the user terminal and a BSF mutually authenticate using the AKA protocol and agree on session keys that are afterwards applied between the user terminal and a NAF. Generally, the BSF restricts the applicability of the key material to a specific NAF by using a key derivation procedure. The key derivation procedure may be used for authenticating to multiple NAFs during the lifetime of the key material. Key lifetimes are set, for example, according to local policies implemented at the BSF.
Although the IMS-AKA authentication procedures and the GBA-AKA authentication procedures both rely on AKA-based authentication, they are conventionally done on separate and independent bases. For example, for the same user terminal, a CSCF contacts the HSS to obtain an AKA vector for authenticating the user terminal in the IMS security domain. Likewise, for the same terminal, a BSF likewise contacts the same HSS to obtain an AKA vector for authenticating the terminal in the GBA security domain. Thus, for the same user terminal, duplicate authentication information is generated and maintained.